IBIS Macromodel Task Group

Meeting date: 03 November 2020

Members (asterisk for those attending):
Achronix Semiconductor      * Hansel Dsilva
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Ken Willis
                            * Jared James
Google:                     * Zhiping Yang
Intel:                      * Michael Mirmak
                              Kinger Cai
                            * Alaeddin Aydiner
Keysight Technologies:      * Fangyi Rao
                              Radek Biernacki
                              Ming Yan
                            * Todd Bermensolo
                              Rui Yang
Marvell                       Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology:            Randy Wolff
                            * Justin Butterfield
SAE ITC                       Jose Godoy
SiSoft (Mathworks):           Walter Katz
                              Mike LaBonte
Teraspeed Labs:             * Bob Ross
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark and Justin Butterfield took
the minutes.

--------------------------------------------------------------------------------
Opens:

- Ambrish asked to reserve time to discuss his proposal to make PAM4 threshold
  parameters optional.  Arpad agreed (discussion below).

-------------
Review of ARs:

- None.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the October 27th
meeting.  Michael moved to approve the minutes.  Jared seconded the motion.
There were no objections.

-------------
New Discussion:

Redriver Flow Issues:
Alaeddin reviewed his presentation, "Symmetric Synthesis of (the Essence of)
Existing Re-driver Proposals".  He noted that it contains his own personal
opinions and suggestions.  He noted several goals for the proposal:
  - Keep the non-EQ-adapting case as the default to preserve the existing
    simplicity of the implementation, given that nearly all (perhaps all)
    existing redriver models do not EQ adapt.
  - Extend the standard "symmetrically" so both Tx and Rx models can utilize
    additional inputs seen in earlier proposals if necessary.
  - Preserve the existing flows' requirement that AMI_Init() functions only need
    to be called once.
  - Allow multi-level redriver scenarios to be implemented by looping over the
    redrivers from initial Tx to final Rx.
    
Slide 5:
This further refines the notation conventions he introduced in the previous
presentation.  The index k denotes the kth redriver in the chain, and the post-
channel for k is the same as the pre-channel for k+1.

Slide 6:
Alaeddin noted that in the normal AMI flow the Rx looks at a pre-channel IR,
possibly equalized by the Tx.  The Tx looks at its post-channel IR.  For
redrivers, we want to consider different IRs.  We may want the Tx to modulate
the upstream impulse rather than the downstream IR, for example.  With
redrivers, we can symmetrically continue to define pre and post per each
redriver.  Then, by default, a redriver TX processes its post-channel while a
redriver RX processes its pre-equalized channel.  Post-channels are unequalized
again.

Two new AMI reserved keywords to control the EQ-mode could be introduced to
modify the default behavior (AMI_RED_TX_EQ_MODE and AMI_RED_RX_EQ_MODE).  These
"eq-mode" keywords would have "post (default), pre, both" for a redriver Tx and
"pre (default), post, both" for a redriver Rx.  If, for example, "pre" is set
for a redriver TX, it would take its (equalized) pre-channel response.
Likewise, if "post" is set for a redriver Rx, it would take its unequalized
post-channel.  In the case of "both", the impulse response matrices are appended
with the missing "pre" and "post" impulse responses including crosstalk IRs.
Because post-channels are always considered to be unequalized, AMI_Init
invocations proceed from Tx to Rx and happen only once.

Slide 7:
This details the cases in tabular form.  Alaeddin noted there are 9 possible
cases.  The functions can be derived for the 9 cases, but they are not shown for
brevity.

Slide 8:
Alaeddin said he wants to check and confirm that each AMI_Init is called only
once and make sure the chain of redrivers can be handled by simply iterating
from left to right.  Assuming there are no major issues, are the desired EQ
adaptation features handled by this proposal?  In terms of handling the
Init-Only models in a redriver scenario GetWave simulation, Alaeddin thinks the
proposal can handle the Init-Only IR changes by folding them into the IR of the
nearest connected channel.  The only exception to this is the case of a redriver
model that combines the Tx and Rx into one.  Alaeddin said this is a
pathological case, and he wondered if the standard should not allow combined
Tx-Rx redriver models.

Arpad asked about the AMI_Init being called once and if it is possible to do
what is proposed on slide 6.  Alaeddin replied the post channel would continue
to be used in this proposal.  The redriver Rx would be invoked before the
redriver Tx.  When we have a redriver, we see its Rx first and then its Tx.
The post IR is the unequalized impulse response.  Arpad said that Walter had
proposed a parameter to select the pre or post channel IR as the input to the
Tx.  Arpad thought there would be two IRs.  Alaeddin stated, because we are only
considering the channel with no equalization, we only need to invoke the
AMI_Init once.

Hansel asked if we are taking into account the non-linearity and if the source
of the non-linearity is the IV curves or the AMI executable model.  Alaeddin
replied the non-linearities would be in the empirical (GetWave) signaling.
Using the modified IRs in the AMI_Init calls allows for faster adaptation and
reduction of the Ignore_bits for the GetWave calls.

Arpad noted an email from Walter that had said that the existing flow works
fine except for certain problematic combinations of Init-Only, GetWave-only,
and Dual models.  Alaeddin said he thought his proposal could handle Init-only
models by lumping their contribution into the nearby channel.  Aside from the
pathological lumped Tx-Rx redriver model, which deprives us of a single channel
connecting to each model, the contributions can be folded into the nearest
neighbor channel.

Ambrish asked to clarify that Alaeddin's slides were not discussing any GetWave
portion of the flow.  They were all concerned with AMI_Init calls and their
modification of the IRs.  Alaeddin agreed, though he reiterated that having all
the IR contributions at AMI_Init time is very helpful for reducing Ignore_Bits
in the GetWave flow.  Ambrish said it would be helpful if Alaeddin could add
some figures to show how the notation (pre, post, etc.) maps to the various
portions of the channel.  Alaeddin said he would add some pictures.

Arpad shared a presentation from July 13, 2010 (ATM work archive) in which Todd
Westerhoff had introduced a similar mathematical notation and enumerated 9
equations for the various combinations of model types.

Fangyi noted one concern about the proposed notation.  If the Rx modifies the IR
and is applying DFE, then it's not convolution.  He said the notation could be
confusing on the Rx side for this reason.  

PAM4 threshold parameters discussion:
Ambrish discussed the PAM4_UpperThreshold, PAM4_CenterThreshold and
PAM4_LowerThreshold parameters (pg. 255, IBIS 7.0).  He noted that the Required:
field says "No", they are not required.  However, the Usage Rules: state that if
the Modulation parameter contains "PAM4" as a choice then PAM4_UpperThreshold
and PAM4_LowerThreshold are required (PAM4_CenterThreshold defaults to 0.0V if
it isn't declared).

Ambrish suggested that we remove the language requiring the upper and lower
thresholds.  He said that providing these values may be a bit cumbersome for the
model maker, and EDA tools typically have to compute the thresholds themselves
anyway.  If the model advertises that it returns them that's great, but the
model shouldn't be required to return them.  Ambrish said it's especially
troubling if the model returns values that don't jive with the simulation
results.  It could cause problems for the tool.  Ambrish said all EDA tools have
to be able to come up with thresholds themselves anyway.  Ambrish said the EDA
tool could compute these values over the entire length of the simulation, where
the model would be limited to computing them over the blocks of data it saw.

Arpad summarized the email discussion from the ATM list.  He said there's a
publicly available algorithm to compute these thresholds from the IR, and tools
can implement that or their own improved methods.  So, the tool can do it.
Arpad noted that he had run into a case where the model returned bad threshold
numbers that were incompatible with the simulation results, and this had caused
problems.  Ambrish noted that in the email exchange Walter had said he was okay
with making the parameters optional.  Arpad said his issue is still the same,
even if the parameters are optional.  The model could still return incorrect
threshold values, and the tool has to deal with it.

Fangyi said that the tool should always use what the model returns.  If the
model returns something that is incorrect, then the model is bad.  He said it's
analogous to the CDR modeling.  If the model returns clock ticks that are not
close to the nominal value then the CDR failed, and the tool should not try to
correct the model.  You have no way of knowing what valid results would be.

Fangyi said he too was okay with making them optional.  However, he noted that
Walter had also said that a good PAM4 model should always return the thresholds.
Ambrish asked if the EDA tool wasn't better able to generate these thresholds.
Fangyi said that in a physical device these thresholds are determined by the
device, similar to the CDR.  Fangyi said he had originally introduced these
parameters so the model could return the thresholds as they varied over time.
Curtis said if you're using a cookbook algorithm to compute the thresholds
from the IR, then the EDA tool can do it just as well.  However, if you want an
idea of what the actual hardware is doing, then only the AMI executable model
can provide that.  Fangyi agreed.

Ambrish noted that the model is not forced to return clock ticks, i.e., not
forced to provide a model of the CDR.  So, continuing that analogy it should
also not be forced to provide these thresholds.  Arpad asked if Ambrish wanted
to draft a BIRD.  Ambrish said he would work on drafting a BIRD.  Arpad
suggested that he enumerate the allowed combinations if they are all optional,
for example, if the upper threshold is provided then the lower threshold must
also be provided.  Hansel suggested Ambrish make sure table 27 is updated if
necessary.

- Curtis: Motion to adjourn.
- Michael: Second.
- Arpad: Thank you all for joining.

AR: None.

-------------
Next meeting: 10 November 2020 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
